|
|
|
|
|
|
|
Assessing Terminology and Traceability |
|
|
|
|
|
|
|
|
In refining the artifacts of your projects, you must be careful about being able to trace key concepts between the artifacts. Although some of your classes will not appear in your use cases, it is very likely that the core subsystems and components in your application will be traceable from your use cases through your Visual Basic code. Avoiding putting business validation logic in your forms ensures that you can effectively trace terminology. Having business logic embedded in your forms means that some key concepts haven't been properly identified; you and your team will not be able to trace user requirements properly. Even for personal individual projects, it is very wise to separate key core application logic from the form. Often, you and most developers will create a Visual Basic application one month, leave it for a while, and then return to it much later, only to find you don't quite remember what the code means. Having a clean separation of concerns between the formswhich are part of the graphical user presentationand the core architecture of the application goes a long way toward creating a well-preserved, reusable application. Developing such an application maximizes traceability of key user terminology. |
|
|
|
|
|
|
|
|
Domain-Specific Terminology for the Samsona Bank Teller Example |
|
|
|
|
|
|
|
|
Your client at the Second Bank of Carrollton has come to realize that you will often make discoveries related to domain terminology as you elaborate your use cases and other artifacts. With each discovery, you have to validate it with the branch manager and key bank tellers. As part of the Elaboration phase, you now need to elaborate the use cases you have. Your problem statement was revised earlier in this chapter to reflect new discoveries as needed. The repeated descriptions in the problem statement calls for a sharing of common events among use cases. To structure your use-case model to reflect this sharing, you typically show a uses relationship between use cases. You can also use the extends relationship, but this is less common and a little more advanced, so ignore the extends relationship. Figure 10.1 shows the latest use-case model. |
|
|
|
|
|